Skip to main content

Introduction

LIVE Lock API is used by OEMs and enterprise customers to integrate the LIVE Lock family of locks to their own mobile applications.

There are two parts to the integration.

The first is the use of InVue's mobile SDK to build the actual mobile app. The SDK handles the communication with the locks. This lock abstraction simplifies the integration as it handles all the low-level bluetooth communications as well as handling all the secure transactions between locks/keys and customer certificate.

The second part of the required integration is described here. It consists of APIs used to register (provision) locks in order to get the key certificates that will be used by the SDK to perform the unlock operations. This provisioning process requires the extraction of the provisioning code from the lock, which is handled by the mobile SDK.

Typically, the integrator backend will store the keys and provide them to mobile applications as needed based on the mobile app's location and its possible interactions with locks. Typically, the keys are grouped by the application by store, and the location of the device limits interactions to those locks in proximity in the store. However, those implementation details are the responsibility of the integrator, the LIVE Lock APIs are unaware of the lock's locations, so this must be managed at the application level.

Overview of a complete system

Live Locks API System Overview As can be seen in the diagram above, the integrator's mobile application is typically connected to a backend. The mobile SDK is embedded in the Mobile App.

When licensing this API, you will get a set of secrets that should be kept in a secure location. They are your keys into the system. Below are the included secrets.

  • API Key

    This key is unique to you and encodes both your identity and API access rights. This identity is important as it will be used to generate Lock Key certificates.

  • The Intermediate Certificate

    This certificate was generated for you and signed by InVue’s Root Certificate. It is necessary to pass this certificate to the mobile SDK. This certificate will be used by the locks to validate the trust chain from InVue passing by your own trusted certificate. All your keys are signed with your certificate. This trust chain is used to ensure that the key alone is not enough to unlock the lock and that the certificate of the owner of the key checks out as well.

Typically, your Intermediate Certificate will be stored on your backend and passed in to the mobile app in the initialization phase of the app.

Enrolling a lock

When the app discovers a new lock (a lock with the provisioning bit set to 0), it should issue a request for a key certificate. In the example above, the enrolment code is passed to the backend which in turn calls the LIVE Lock API to register the lock. The LIVE Lock API will return a Key Certificate that is specific to that lock--it is the key to that lock. The Mobile SDK will require that Key Certificate every time an unlock is requested for that lock. The unique key to this Lock and Key Certificate is the lock's serial number. Management of Keys and Lock locations is the responsibility of the implementor.

Customer Intermediate Certificates

Your Customer Intermediate Certificate will need to be renewed at the interval required by your licensing agreement. You will need to take this in consideration while designing the application. On renewal, all certificates will need to be renewed on the mobile devices, your software should account for this as expired certificates will not permit the unlocking of locks.

Note that the renewal of the Customer Intermediate Certificate does not affect the issuance of Key Certificates and those will not need to be renewed, only the Intermediate Certificates requires renewal.